The invention relates generally to graphical block diagram modeling.
Dynamic systems may be modeled, simulated and analyzed on a computer system using graphical block diagram modeling. Graphical block diagram modeling graphically depicts mathematical relationships among a system's inputs, states and outputs, typically for display on a graphical user interface.
In the context of graphical block diagram modeling, blocks are graphical structures that have a defined functionality. Such blocks can be interconnected by lines to form subsystem blocks that implement a function or an algorithm. An example of a block is a gain component acting as a multiplier to an input signal and an example of a subsystem block is the gain block being used to amplify an input signal generated by an input signal block. Subsystem blocks may in turn be connected to and contain other subsystem blocks, thus allowing for a hierarchical design structure and representation of more complex functional units. Continuing with the same example as above, the amplified signal may be used to drive a more complex system such as a modulator. Such subsystem blocks may be placed in a reference library to define a graphical class. Graphical libraries are similar to system software libraries in that they are a repository of classes. These classes, or more specifically, graphical classes, can be used by multiple users to build custom systems. When a graphical class is used in a model, it is said to be instantiated, i.e., an instance of the graphical class is created for use in the model. Such an instance can also be referred to as a link to the graphical class that resides in the library. Parameters are class members that are specified when a user constructs a new instance of a class. In the subsystem block example above, the signal type and the gain factor could potentially be parameters for the graphical class. Instances associated with the class have parameter specification interfaces that allow a user to define these “top-level” parameters. On a graphical user interface (or “GUI”), such parameter specification interfaces take the form of a dialog box with various parameter fields. A user can therefore change the top-level parameters of an instance by changing parameter data in a parameter field in the dialog box for that instance.
Prior block diagram modeling and simulation software packages, e.g., Simulink® version 3.0 and SystemBuild™, allow only values of top-level parameters of an instance to be changed. Typically, to modify an individual block within a graphical subsystem block in a library (and therefore modify behavior of the subsystem block), a user has to make a local copy and apply any changes to that local copy. This approach is problematic, however, in that the local copy does not inherit any changes or improvements made to the original class. As a result, the local copy (in essence, a new class) quickly diverges from the original class and inclusion of the changes to the original class in the new class requires that the new class be updated manually. Another approach would be to specify all parameters of all of a subsystem block's components at the top level. This can, however, get extremely complicated for non-trivial classes and prove to be unusable.